Facts and Fallacies of Software Engineering
My thoughts
25 Mar 2017
View Comments
#programming
#facts
#fallacies
#bookreview
I have just finished reading the Facts and Fallacies of Software Engineering by Robert L. Glass. There are 55 facts and 10 fallacies of Software Engineering presented in this book. Although most of the facts make sense, I do not agree with every fact discussed in this book. I would like to elaborate on some of the disagreeing facts and emphasize on the facts I strongly agree. I do not wish to discuss on fallacies as they could be confusing to discuss in the mixture.
Facts I do NOT necessarily agree
This book was written in 2002 which is pretty old. I adapted this book when I was in university and software engineering had a different meaning than today. I wanted to particularly read this book because it has been more than a decade after it was published. I wanted to see how the technologies evolved after the publishing. Below are just the facts that I would like to make some extra comments on. They are not wrong even after all the years went by.
Reuse-in-the-large remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
Back in the time of early 2000, we probably lacked a good structure to write codes in a cleanly manner. Certainly, there was no good repository branching model to the wide audience. We had too many choices of software development methodologies and standards. However, unless you are using some old legacy code, it has gotten pretty easy and accessible to reuse the code not only written by you but everyone in the world.
Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.
As long as there is a good procedure of reviewing the code changes and that you have the confidence with testing, you should be able to make changes even on the code being reused. It is totally possible to break something out of this reusable code, however, a programmer should code the reusable code as generic as possible and remain the function in that fashion.
Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability
Quality might be really important for the programmer, but this might not be so important to the company. The company might be satisfied with the Quality as long as users are satisfied. The definition of the quality might be changing depending on who and what you are working on.
Facts I do strongly agree
I certainly nodded on some of the facts discussed. I found these facts not controversial at all but wanted to expand on what had been discussed in the book.
The working environment has a profound impact on productivity and product quality
I did notice this to be quite effective. When I first started working as a software developer, it was a cozy little space in Richmond. As it was my first job, I really didn’t have any idea about what good environment actually mean. Then I moved to the even smaller company, things were generally relaxing but literally, it was too relaxing! Then I joined mid-sized company which had more than 200 devs. This company was a big turning point for me. It had fairly well-built structures and management. I actually found myself to be a lot more productive. Then I am in a bigger company now. Things are much more organized here and I find they tend not to bother me a lot and let me focus on what I like to do which is programming. I honestly believe growing career starts with having a good working environment!
It is nearly impossible to do a good job of error removal without tools. Debuggers are commonly used, but others, such as coverage analyzers, are not.
It is quite important for the developers to at least use debugger and code coverage to maintain/secure your software. These two should be mandatory if not it is already. I find that extra layer of testings for the coverage are really for the future, not for the present error. It could be breaking as you are updating another area of codes. They tend to be working quite well over the course.
Post delivery reviews (some call them “retrospective”) are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of view of process improvement. But most organizations do not do post-delivery reviews.
Retrospectives for the deployment is important. It is important for both the employee and the employer. It is the place where we can talk about how things went during our deployment and how we could improve next time on these processes. I have noticed the significant increase in deployment efficiencies from the topics that had been discussed in these meetings. An example would be assigning the right point of contacts for the components that we need a help of, which reduced a significant number of bottlenecks that holds the subsequent teams who awaits on these components.
Maintenance typically consumes 40 to 80 percent (average 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software
This is also very true. The author emphasizes the “maintenance” consist of the feature being built in the future, not just on fixing bugs. Changes occur and when those changes happen it could be as little as adding extra columns to entirely changing the methods of communication or systems. It could literally range from 40 to 100 percent of software “cost”. I wouldn’t go below 40 percent as it is impossible for the software not to have bugs or the changes after the software is released. The “cost” we are talking here basically boils down to “time and money” but when you break down the execution of it, it consists of planning, estimating, managing, funding, budgeting, financing etc. So maintenance is not a simple thing we can do in the software cycle.
There is seldom one best design solution to a software problem.
There was a time in my developer life when I thought there always is one best solution we can adapt that would make the software much better. Now, I regret that terrible thought. There probably is the best algorithm to solve problems handed to you. However, software is a different animal. You have options to choose how your software is going to adapt to different systems and components and how it would use those resources. Even simple as communications between servers, you have multiple options to choose and they are normally great and capable of doing what you are trying to achieve, except the people tend to choose the one actually know and used of. My advice on making these choices would go with the most popular one barring that it will do a good job for your software.or your software.
My Overall Rating:
